Many operating systems permit programs to allocate objects for their use. While many different definitions for objects exist, the set of objects discussed herein is relatively inclusive. An object as discussed herein is one of several standard data structures, each for storing data about a particular aspect of a program, such as a picture, also known as a bitmap, or a menu. An object may also contain methods, which are programs for interacting with the data contained in the object. When an object is allocated, a block of memory is reserved to hold the contents of the object. In many operating systems, objects are stored in linked lists, such that either all of the objects of a given type are in the same list or all of the objects "owned" (ownership is described in more detail below) by a particular program are in the same list.
In order to ensure a certain level of reliability, many operating systems implement a system of object ownership. In such a system, the operating system attributes ownership of each object of some, if not all, types to a particular program. A system of object ownership prevents the unnecessary use of some memory resources by permitting the operating system to automatically deallocate an object when the program to which its ownership is attributed terminates. Likewise, a system of object ownership enables the operating system to prevent unauthorized access to an object by identifying, for each object, a program that is permitted to specify which other programs are authorized to access the object.
The level of control that programs are able to exercise over objects when used with a particular operating system depends on the particular object ownership model supported by the operating system. In an operating system that supports laissez faire object ownership models, objects are not owned by any program. An object may therefore be accessed (i.e., read from, written to, or, in the case of an object having methods, invoked) or deallocated by any program that is aware of the object's existence. FIG. 1 is a block diagram of an object as defined in an operating system that supports the laissez faire object ownership model. The diagram shows a laissez faire object 100, the sole contents of which are object data 101. In the case of a bitmap object, the object data 101 corresponds to the color value for each of a number of adjacent pixels. The laissez faire object does not contain any indication of the identity of the program that allocated the object, the programs that may attempt to use the object, the programs that may attempt to deallocate the object, or the program that might be said to be the object's owner. To the contrary, the object has no owner.
In operating systems that support the laissez faire object ownership model, programs are able to informally share an object. Two programs informally share an object when they share the object by consensus and without the knowledge of the operating system. Generally, this process involves a program that wishes to share an allocated object sending a message to that effect to the program that allocated the object. The program that allocated the object responds by providing a way for the sharing program to access the object, such as a pointer or a handle.
FIG. 2 is a timing diagram showing the informal sharing of a laissez faire object. Here, the object is a bitmap object that contains a visual image of a toolbar that is allocated by a spreadsheet program and shared by the spreadsheet program and a word processing program. The timing diagram shows a time scale 200 having the following time graduations: time t.sub.1, time t.sub.2, time t.sub.3, time t.sub.4, and time t.sub.5. The timing diagram also shows a spreadsheet program running interval 210 during which the spreadsheet program is running, a word processing program running interval 230 during which the word processing program is running, and a bitmap object allocated interval 220 during which the toolbar bitmap object is allocated.
A spreadsheet program launch node 211 shows that the spreadsheet program is launched at time t.sub.1. The launch starts the spreadsheet program running interval 210. Together a causation arrow 212 and an object allocation node 221 show that the spreadsheet program allocates the bitmap object at time t.sub.2. The spreadsheet program uses the bitmap object during object use range 222, from time t.sub.2 until the spreadsheet program terminates at time t.sub.4. A word processing program launch node 231 shows that the word processing program is launched at time t.sub.3. The launch starts the word processing program running interval 230. An object use range 223 shows that the word processing program begins using the bitmap object at time t.sub.3. Both objects continue to use, i.e., share, the bitmap object until time t.sub.4. The spreadsheet program terminates at time t.sub.4, as shown by a spreadsheet program termination node 213. Since the word processing program has not finished using the bitmap object, the spreadsheet program delegates responsibility for deallocating the bitmap object to the word processing program. This process involves the spreadsheet program sending a message to the word processing program indicating that the word processing program is now responsible for deallocating the bitmap object. The word processing program then continues to use the bitmap object, as shown by the object use range 223. A word processing program termination node 232 shows that the word processing program terminates at time 15. Together a causation arrow 233 and an object deallocation node 224 show that, because no other programs are using the bitmap object, the word processing program deallocates the bitmap object. After the word processing program deallocates the bitmap object at time t.sub.5, the bitmap object no longer exists or consumes space in memory.
In operating systems that support more rigorous object ownership models, where the operating system assumes greater control over objects, objects are each owned by some program. FIG. 3 is a block diagram of an object as defined in an operating system that supports a more rigorous object ownership model. The diagram shows a rigorous object 300. The object 300 contains object data 301 and an owner field 302. The owner field 302 contains an indication of the program to which ownership of the object is attributed and is typically stored within the object, as shown. As an alternative to storing the owner field 302 with the object 300, the owner field may be stored together with the owner fields for other objects in a central location. Ownership of an object in most such operating systems is initially attributed to the program that allocated the object. Typically, ownership can later be transferred from the allocating program to another program.
Revising an existing operating system to expand the set of object types that are owned further increases the reliability of the operating system. For example, an operating system may be revised to make a new type of object owned. Revising an operating system to expand the ways in which the operating system exercises control over owned objects likewise further increases the reliability of the operating system. For example, an operating system may implement automatic deallocation of owned objects, or may control the set of users or programs that may access owned objects.
In order to reclaim space in memory occupied by objects that are no longer needed, an operating system may implement automatic deallocation of owned objects. In some cases, because of design or implementation flaws, the allocating program fails to provide code for deallocating the objects that it has allocated. In such cases, the allocating program fails to ever deallocate such objects. Because no other program is responsible for deallocating the object, the object survives forever (i.e., until the operating system is restarted or otherwise clears all of its working memory), occupying valuable memory space. Also, in some cases, the allocating program may terminate abnormally. For example, in many operating systems, when the operating system detects a severe error such as a general protection violation or a page fault during the execution of a program, it can terminate the program unilaterally. In such cases, the allocating program is terminated immediately without notice. Immediate termination prevents the allocating program from executing any code it has to deallocate the objects for which it has deallocation responsibility. In such cases of abnormal termination, the objects for which the allocating program has deallocation responsibility and which exist at the time of abnormal termination survive forever. An operating system that implements the automatic deallocation of objects overcomes these problems by immediately deallocating any objects owned by the terminated program. This usually involves traversing the linked lists that connect allocated objects, and deallocating any objects appearing in the linked lists whose owner field 302 indicates that it is owned by the terminated program.
In order to guarantee the security of data contained in objects, an operating system may control the set of users or programs that may access owned objects. Some computer systems use objects that contain sensitive information intended to be used for specific, limited purposes, but not otherwise made available to other programs or users. To this end, an operating system may be revised to control the set of users or programs that may access owned objects. FIG. 4 is a block diagram of an object as defined in an operating system that controls the set of users or programs that may access owned objects. The object 400 contains object data 401, an owner field 402, and a pointer to an access control list 403. The owner field 402 contains an indication of the program to which ownership of the object is attributed. The pointer to an access control list 403 points to an access control list 410. The access control list 410 contains a series of list entries, including list entries 411 and 412. Each list entry identifies a program that is authorized to access the object 400. In some operating systems, a list entry may designate a group of programs. Such a group may include the group of programs being executed for a particular user. Also, in some operating systems, a list entry may specify the particular type of access to be permitted by the designated programs, e.g., read, write, or invoke. In such an operating system, when a program attempts to access the object 400, the operating system examines the list entries in the access control list 410 to determine if the program is authorized to access the object 400. If the operating system locates a list entry authorizing the program to access the object 400, then the operating system provides the program with access to the object, else the operating system returns without providing access to the object.
Many operating systems implement automatic deallocation of owned objects or control the set of users or programs that may access owned objects, as this tends to make the object ownership model supported by an operating system more rigorous, and therefore the operating system more reliable. Because the purpose of making an operating system's object ownership model more rigorous is to give the operating system more control over objects, a more rigorous object ownership model necessarily leaves programs that are used with the operating system with less control over the objects with which they interact. Developers of programs that are developed for use with an operating system that supports a rigorous object ownership model are able to adapt the programs to require less control over the objects with which they interact. However, many programs that have already been developed for use with an operating system that supports a less rigorous object ownership model have and retain dependencies on the ability to exercise the level of control over objects that is possible in connection with the operating system that supports a less rigorous object ownership model. When these "old" programs developed for use with an operating system supporting a less rigorous object ownership model are used with a "new" operating system supporting a more rigorous object ownership model, these dependencies of the old program are consistently violated. This usually occurs in cases where old programs, presuming a higher level of control over objects than a new operating system permits, attempt to informally share an object.
FIG. 5 is a timing diagram that illustrates how a new operating system that implements automatic object deallocation can frustrate the attempts of old programs developed for operating systems without automatic object deallocation to informally share an object. The timing diagram depicts the consequences of the same series of events in connection with old programs shown in FIG. 2 in an operating system that implements automatic object deallocation. The timing diagram shows a time scale 500 having the following time graduations: time t.sub.1, time t.sub.2, time t.sub.3, time t.sub.4, and time t.sub.5. The timing diagram also shows a spreadsheet program running interval 510 during which the spreadsheet program is running, a word processing program running interval 530 during which the word processing program is running, and a bitmap object allocated interval 520 during which the a bitmap object is allocated. The timing diagram further shows an automatic deallocation system running interval 540, which indicates that the portion of the operating system responsible for automatic object deallocation is always running.
A spreadsheet program launch node 511 shows that the spreadsheet program is launched at time t.sub.1. The launch starts the spreadsheet program running interval 510. Together a causation arrow 512 and an object allocation node 521 show that the spreadsheet program allocates the bitmap object at time t.sub.2. The operating system sets the owner field 302 of the bitmap object to indicate that the spreadsheet program owns the bitmap object because the spreadsheet program allocated the bitmap object. The spreadsheet program uses the bitmap object during object use range 522, from time t.sub.2 until the spreadsheet program terminates at time t.sub.4 . A word processing program launch node 531 shows that the word processing program is launched at time t.sub.3. The launch starts the word processing program running interval 530. An object use range 523 shows that the word processing program begins using the bitmap object immediately at time 13. Both objects continue to use, i.e., share, the bitmap object until time 14. A spreadsheet program termination node 513 shows that the spreadsheet program terminates at time t.sub.4. Although the spreadsheet program attempts to delegate the responsibility for deallocating the bitmap object to the word processing program, causation arrow 541 shows that the automatic deallocation system deallocates the bitmap object as the spreadsheet program is terminating at t.sub.4 because the spreadsheet program is the owner of the bitmap object. An object use range 523 shows that word processing program uses the bitmap object from t.sub.3 until the spreadsheet program terminates at t.sub. 4. An object nonuse range 533 shows that the word processing program is unable to use the bitmap object from t.sub.4 until the word processing program terminates at t.sub.5. This amounts to a frustrated attempt by the word processing program to share the object during the object nonuse range 533. The same result occurs any time the program that allocated an object terminates before sharing of the object concludes.
FIG. 6 is a timing diagram that illustrates how an operating system that implements object access control can frustrate the attempts of old programs developed for operating systems without object access control to informally share an object. The timing diagram depicts the consequences of the same series of events in connection with old programs shown in FIG. 2 in an operating system that implements object access control. The timing diagram shows a time scale 600 having the following time graduations: time t.sub.l, time t.sub.2, time t.sub.2.5, time t.sub.3, time t.sub.4, and time t.sub.5. The timing diagram also shows a spreadsheet program running interval 610 during which the spreadsheet program is running, a word processing program running interval 630 during which the word processing program is running, and a bitmap object allocated interval 620 during which the bitmap object is allocated. The timing diagram further shows an access control system running interval 650, which indicates that the portion of the operating system responsible for object access control is always running.
A spreadsheet program launch node 611 shows that the spreadsheet program is launched at time t.sub.1. The launch starts the spreadsheet program running interval 610. Together a causation arrow 612 and an object allocation node 621 show that, at time t.sub.2, the spreadsheet program allocates the bitmap object. The operating system sets the owner field 402 of the bitmap object to indicate that the spreadsheet program, because it allocated the bitmap object, owns the bitmap object. Because the old spreadsheet program was not developed with access control in mind, it does not explicitly designate any access control list entries to authorize the use of the object by other programs. The operating system, however, sets the access control list pointer 403 to point to a default access control list designating access authorization only to the object's owner, the spreadsheet program. A causation arrow 651 shows that, at time t.sub.2.5, the spreadsheet program requests access to the object. The access control system receives the request, and examines the list entries in the access control list 410 to determine if the spreadsheet program is authorized to access the object 400. A causation arrow 652 shows that, because the access control system locates an access list entry authorizing access to the object by the spreadsheet program, the access control system provides the spreadsheet program with access to the object. The spreadsheet program uses the bitmap object during object use range 622, beginning at time t.sub.2.5. A word processing program launch node 631 shows that the word processing program is launched at time t.sub.3. The launch starts the word processing program running interval 630. A causation arrow 653 shows that, at time t.sub.3, the word processing program requests access to the object in order to share the object. The access control system receives the request, and examines the list entries in the access control list 410 to determine if the program is authorized to access the object 400. A causation arrow 654 shows that the access control system declines to provide the program with access to the object, because no access control list entry appears in the access control list authorizing access to the object by the word processing program. This amounts to a frustrated attempt by the word processing program to share the object during the object nonuse range 633. The same result occurs any time a program other than the one that allocated an object attempts to access the object.
It can be readily seen from the foregoing examples that programs developed for operating systems that support a laissez faire object ownership model may perform undesirably when used with an operating system that supports a more rigorous object ownership model, such as one that incorporates automatic object deallocation or object access control.